Floppyshop 2

home *** CD-ROM | disk | FTP | other *** search

/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0105 / zmag130.txt < prev next >

Wrap

Text File | 1997-04-16 | 35KB | 783 lines

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* SYNDICATE ZMAGAZINE Issue #130 November 6, 1988 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Publisher/Editor: Ron Kovacs Post Office Box 74 Middlesex, NJ 08846-0074 CONTENTS *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* (#) Editors Desk.......................Ron Kovacs (#) ZMag Newswire................................ (#) Zmods (1200XL Modification)....Charles Koontz (#) Notes on Programming..........Ctsy Atari8*SIG (#) ZMag Newswire Part 2......................... (#) ST Section................................... (#) PC Pursuit Recommendations................... *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* This issue conveyed via Paybax BBS. 302-731-5558. All bauds. *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Editors Desk ----------------------------------------------------------------------- We are back on GENie in the Atari 8 Bit RT. Our NEW GEnie Mail address is ZMAG. Please make a note of this if you want to contact us in the future. November 8th is here and it is your RIGHT and NEED to vote. The ritual of elections cannot be complete if we DO NOT take advantage of this right. Please attend the Formal Conference on CompuServe November 9th at 9pm EST. The guests for this CO will be Ralph Mariano, Editor of our sister publication ST-REPORT. I will also be there to field your comments and questions. Enter GO CONVENTION at any CompuServe prompt to enter this CO area. Please give the SELECT BBS a call at (916) 392-7279! November 8: Election Day November 10: Day of Founding of the Marines 1775 November 11: Veterans Days November 13 - 19: American Education Week! Thanks for reading ZMAGAZINE! ZMag Newswire ----------------------------------------------------------------------- SUNNYVALE (NOV 1) USA Today: Atari reported they will be giving credit for purchasing Atari cartridges. They are sold presently at a cost of $10 to $30 each. Also stated in the article, Atari will give prizes and give away a two week vacation. If this expirement works, they will continue this promotion as a way of luring more people to purchase Atari products. COMDEX UPDATE: (NOV 6): Atari failed to register on-time for the Comdex preview. (Ed. Hope this isn't s sign of things to come.) The Laptop seems to be the highlight scheduled along with desktop publishing displays. Z-Mods ----------------------------------------------------------------------- Atari 1200XL Split Chroma Modification by Charles D. Koontz This easy modification to the 1200XL provides a true chroma output to the 1200XL monitor jack. It allows the use of "split video" monitors for sharper images and truer color. This modification involves installation of one wire to the foil side of the 1200XL main circuit board (motherboard). Now to get the usual tiresome, but necessary, warnings out of the way: This modification is installed at the risk of the user. Any warranty on the 1200XL will be invalidated. The author assumes no responsibility for damage done during, or by, the modification. EQUIPMENT REQUIRED: (1) Screwdriver - Phillips head (1) Screwdriver - blade (1) Soldering iron & solder (1) Wire cutter or knife THE MODIFICATION 1. Disconnect all power, TV, stick, paddle, drive, MIO, etc. from the 1200XL. 2. Turn the 1200XL upside down on your work surface. 3. Remove the six Phillips head screws securing the bottom of the 1200XL to its top. 4. Carefully holding top and bottom together, turn the unit upright. Move the top away from you, exposing the keyboard ribbon cable connectors. 5. Make a note of the mating polarities of the keyboard ribbon cable and its connector. 6. Push the keyboard connectors away from you, disconnecting the top and keyboard from the motherboard. 7. Remove the top (and keyboard) assembly and lay it aside. 8. Remove six Phillips head screws which secure the motherboard to the bottom shell. 9. Remove the left plastic cartridge and joystick frame and lay it aside. 10. Remove the motherboard from the plastic bottom shell. Lay the bottom shell aside. 11. Using a flat blade screwdriver, gently pry up eleven "pop" fasteners that secure the top and bottom shields to the motherboard. 12. Position the motherboard in front of you just as it would be if it were still in the 1200XL. 13. Find transistor Q19 in front of, and slightly to the right of, the large upright cylindrical electrolytic capacitor (C39) at the right rear of the motherboard. 14. Just to the left of Q19 is capacitor C118. The left lead of C118 is where the chroma signal appears. Find its connector on the foil side of the circuit board and solder one end of an insulated hookup wire to it. 15. Before cutting the other end of the wire to length, carefully route it so it will fall under one of the elevated areas of the bottom shield edge when the shield is replaced. The other end of the wire must reach pin 5 of the monitor output jack J2. 16. Solder the other end of the hookup wire to pin 5 (the unused connector) of the monitor output jack J2. 17. Carefully re-position the top and bottom shields on the motherboard, making sure the new wire is not pinched by the shield edge and the insulating sheet is in place under the bottom shield. 18. Fasten the shields to the motherboard by pressing the eleven "pop" fasteners into place. WARNING - BE CAREFUL NOT TO CUT YOURSELF ON THE SHIELD EDGES. 19. Position the motherboard in the plastic bottom shell. Position the left plastic cartridge and joystick frame in place. 20. Fasten the motherboard to the bottom shell with six Phillips head screws. 21. Position the keyboard and top unit on top of, and slightly to the rear of, the bottom. 22. Reconnect the two ribbon connectors from the keyboard to the motherboard. a. Large black connector is fastened without twisting its short ribbon cable. b. Small black connector is fastened with the red stripe on its small grey ribbon cable to your left. 23. Move the top unit into position over the bottom. 24. Holding the top and bottom together, turn the unit upside down. 25. Fasten the top and bottom together with the remaining six Phillips head screws. 26. You're done!!! Find a monitor cable terminated with four phono plugs and you're in business. Radio Shack has such a cable. (If it's the same as mine the plugs are: black-audio, red-luminance, yellow-chrominance, white-composite but unused with a split video monitor like the Commodore 1702.) On the chance that your cable is wired differently, some experimenting will be necessary to find the right hookup. Plug the din connector end into the 1200XL monitor jack. Turn on the 1200XL and run a disk or cartridge program that uses sound. (Donkey Kong?) a. Find the audio plug by sequentially plugging each plug into your monitor's audio input jack. MARK IT! b. Find the luminance plug by sequentially plugging the remaining three plugs into your monitor's COMPOSITE VIDEO jack (not the luminance jack). You'll know you have the right plug when you get a monochrome picture. MARK THE PLUG and move it to the monitor's luminance jack. c. Find the Chrominance plug by sequentially plugging the remaining two plugs into your monitor's COMPOSITE VIDEO jack (not the Chrominance jack). When you get a fine color picture, MARK THE PLUG. That is the composite video plug. It remains unconnected. d. The remaining plug carries the chrominance signal. MARK IT. Connect it to the monitor's chrominance input jack. e. Why are you reading this step? The modification is done and your 1200XL is properly connected to the monitor. Play DONKEY KONG. Seriously, if you have trouble, leave electronic mail for me at: GEnie - CHARLEKOONTZ CompuServe - 74206,3444 Notes on Programming ----------------------------------------------------------------------- Ctsy: CompuServe Atari 8 Bit SIG Sb: #PROGRAMMING Fm: ROBERT ABRAMS 73547,1552 To: KEITH JOINS 72347,75 Keith, I would like to ask you a few questions with regard to binary files. If I am wrong, please correct me. Binary files are either created with the Atari Assembler Editor or the MAC/65. Is this correct? Now, if a Basic program is compiled with a compiler, is it turned into a machine language file? According to my DOS 2.5 manual and some other texts on Atari basic, with regard to "Option K" in DOS, to save a file using the "Binary Save" option, the format is as follows: SAVE-GIVEFILE,START,END(,INIT,RUN) Now, the START= the beginning of the program's address and the END=the end of the program's address--both of which are given in hexadecimal numbers. INIT and RUN, respectively, are used if one wants the program to automatically execute on loading. Does this mean that if a binary file is saved without the INIT and RUN addresses, when it loads it will not run? If this is the case and if someone saved a file without INIT and RUN addressses, would they then use Option M -RUN AT ADDRESS from the DOS menu to get the binary program to run? Now, the format to save a binary file (and to get it to run (execute) on loading is: FILENAME,START,END(,INTI,RUN) Question, how does one find out what the START,END, INIT and RUN addresses are? Does the Atari Assembler Editor/MAC/65 provide this information? Is it correct to say that one can't save a Basic file as a binary file unless it is compiled? After compiling, how does one find out where these respective addresses are? Does the compiler provide this? Lastly, with regard to the USR statement in Basic. Format: USR(memadr[,numexpr...]) Example: A=USR(1536),ADR(A$),ADR(B$)), How does one find the "memadr," i.e., the starting address of the machine language program? In the above, the ",numexpr" is also called an "argument." Below is a hardware stack. Please explain this to me. I am lost USR COUNT ---------------- 1ST USR Argument ---------------- 2nd USR Argument ---------------- . . . . . . ----------------- Final USR Argument ------------------- Basic Program's Return Address ------------------- Stack Contents Prior to USR --------------------------------------- How does one know what the Basic program's return address is? Now I understand that that a machine language program can return to Basic by executing the assembly language RTS instruction. I am kind of lost here, I guess for anyone to get Basic to use the USR one must have a background in assembly. Is that correct. However, there is a commercial product that has many Basic subroutines that perhaps I could use to apply the USR/RTS statements. I am really interested in this stuff. I tell, this just fanscinates me. Getting back to what I was saying, I believe the software is called "QuickCode". Have you heard of this. If yes, what do you think of it? Perhaps you could help me with this stuff. Should only a person who is into assembly use the Basic USR/RTS statements? Are there machine language subroutines avilable to the Basic programmer to help this person do things with Basic that can't be done otherwise. Perhaps this "QuickCode" is what I am looking for. It could certainly help me with Basic and Assembly. I understand it works with the MAC/65. Phew!!!!!! I'm done now and I am still lost. Bob Fm: Keith Joins/Sec. Leader 72347,75 To: ROBERT ABRAMS 73547,1552 Bob... Just a couple of questions, eh? Whew! <grin> OK--Mac/65 and the Atari Assem/Editor do produce binary files. However so do such things as Action, a 'C' compiler, Lisp and any other language that produces a machine lanuage (binary) type object file. Basic is a kind of interpreted language. What that means is that the basic code or actually the basic tokens are changed to machine language instructions as the program is run. That is why it is so much slower than a binary file. A basic compiler changes the basic code to the machine language instructions prior to running and saves them as a binary file of sorts. Your next question requires a little understanding of how a binary file is created or stored. It will always begin with a header of 255 255 which is FF FF in hex. Next are four bytes that indicate the start and end address of the file, or the first segment of the file. This is the memory address that the file will load into. Then you will have the actual data, the total number of bytes here being equal to the number of bytes between the start and end address. Now you are either at the end of the file or you could have a second segment of the same program. If you have a second segment, then the next four bytes will again be the load addresses, start and end. FF FF could be repeated, but is not necessary. This can be repeated as often as you want. The INIT address is used to cause an immediate execution at the address specified when THAT segment is loaded before the rest of the program is loaded in. (sound familiar from your question about screens being loaded?) The RUN address is used when the entire program has loaded. An INIT address is not required to have a program run automatically but a RUN address is. If no RUN address is specified in a program, then you have to use option 'M' from DOS to execute the program after loading it. In assembly, you specify the start, run, and init addresses. The end pretty much takes care of itself. The start address is determined by where you assemble the program in memory. The RUN address is where your program begins execution. These two are not necessarily the same. To set up your run address you simply place the address your program begins execution at in memory locations 2E0-2E1. After the program is loaded, the computer will jump to the address contained in these two locations. Most assemblers allow you to assemble directly to disk. However you can assemble your program to memory and then use the DOS option 'K' to binary save it, specifing the RUN address and the INIT address if needed. Again these are addresses that you have set up in your program. The start and end addresses are still based on where you assembled your program to in memory. You can't really binary save a basic program since the tokens will not mean anything to the computer until they have been translated into ML instructions. With a USR call from Basic, the address of the routine is either a specific address such as 1536 that you mentioned, or the address of a string that contains the ML routine. If the ML routine is in a string then you really don't need to know what it's address is since Basic handles that for you with the ADR command. The stack is 256 bytes of memory (page one) that is reserved for keeping track of a bunch of values your computer needs to navigate with. It is a last in-first out type of operation. In other words, the last value placed there will normally be the first one removed. When you do a USR call, the return address of your basic program is first placed on the stack. You don't really know or care what it is, much different from an assembly program where you might want to change the return address of your JSR. The next thing placed on the stack are any parameters passed with the USR call, such as ADR(A$) and ADR(B$) in your example. Finally the number of parameters passed is placed on the stack. If there are no parameters then this would be a zero, but it is ALWAYS placed there. Now your ML routine takes over. The first instruction of a ML subroutine used by a Basic USR call is PLA or 104 decimal. If you look at basic programs that have the routine in data statements, you will always see this 104 as the first number. This is because you have to do something with the first value coming off the stack--the number of parameters passed. Even if you don't want it for anything, you have to get it off the stack or your program will crash. You then use the PLA instruction to get the parameters themselves from the stack and do whatever you want with them, according to the function of the ML subroutine. The stack is then untouched until your subroutine encounters an RTS when it is finished. The RTS will pull the return address of your basic program off the stack and that is where execution resumes. Again note that each value on the stack was used in the reverse order that they were placed there. Also remember that parameters are optional. To write your own USR routines you do need to know assembly. I am familiar with QuickCode and in fact own the product. I have used it some and it does it's intended function well. It is a collection of Macros for Mac/65. A Macro is a series of instructions that are stored together with a name. When the assembler encounters the macro name, it substitutes the stored lines in place of the name in your code. This lets you define new commands or operatives. The macros in QuickCode are used to establish these commands, such as COLOR, GR., OPEN, CLOSE, etc that are not valid assembly instructions. Using the output of these routines for basic USR routines would be of limited value. QuickCode does not produce relocatable code so any routines created with it would have to be placed in a specific memory area where it was assembled at. There are very few places in memory that are protected and that would be of the size needed. Macros produce large object files since the actual macro code replaces the macro name every time it is encountered. Page six would normally not be big enough. QuickCode could be of use to you in writing a totally ML program as it does help with things that you would normally have to write yourself. The macros can also be turned into subroutines for use in your programs. There are some ready-to-use subroutines that can be used in your Basic programs, depending on what you want to do. I think I recall seeing an ad recently for a disk of such. I am not at home right now so I can't check for sure. Let me know if you are interested and I'll see if I can find it. Bottom line--if you want to use USR for what YOU want, learn assembly. Keith ZMag Newswire -- Part 2 ----------------------------------------------------------------------- **Press Release** Innovative Concepts (I.C.) 31172 Shawn Drive Warren, MI 48093 CompuServe: 76004,1764 Phone: (313) 293-0730 Note: The following NEW products, will be available for sale, starting November 11, 1988 (advance orders are welcomed). The XF35 Kit ------------ For Atari XF551 owners, now it's EASY to upgrade your set-up, to use the newer 3.5" drive! Allows you to store up to 720K on each disk! Fully tested, to work with: MyDOS, SpartaDOS (ICD), and the new SpartaDOS X cartridge (ICD), in the 720K (80 tracks/side) format. And, 40 track formats are still available, for use with most other DOS's. Also, the high speed skewing is still available to use, in the upgrade ROM. Kit includes: Installation/User instructions, Upgrade ROM, and all required connecting cables. Note: To allow for easier access, the XF551's - 34 pin connector (J4), is desoldered, and replaced with a 34 pin header connector. NO other soldering/desoldering is required. And, NO trace cutting to perform. Everything else, is "just plug ins"! Note: The 3.5" drive mechanism, and it's mounting bracket, are not included in this kit. (see below) Price: $34.95 (+ $3.00 S&H) Note: A COMPLETE conversion kit, including all of the above, PLUS: A High Quality - 3.5" 720K drive mechanism, mounting bracket, with the SpartaDOS Construction Set (ICD), are also available. Call or write, for more details. The IC Chip ----------- Now, Atari 1050 owners with the Happy Board installed (original or clone), can now boot-up SpartaDOS skewed disks, WITHOUT having to go into the U.S. Emulation Mode anyore! A REAL time-saver! Automatically adjusts to U.S. Emulation mode, when a program or utility, is "looking" for a U.S. Doubler (ICD), such as SpartaDOS or CopyMate 4.4 (an excellent sector copier). Includes: Instructions, Upgrade ROM, and 2 disks (both sides), full of Happy-type programs and utilities. Note: Just as before, you still CANNOT format U.S. sector skewed disks. However, you can still read and write to them. All other Happy functions, are still available. Installation, is just a matter of unplugging the Happy 1050 Board's ROM, and installing this new one. NO soldering, desoldering, or trace cutting required! Price: $29.95 Also, see our current catalog, for our Immitator Controllor, which is another great add-on, for the Happy 1050 Board (original only). Ramdrive + 192K --------------- Due to the current high cost of 41256 DRAMS, we at I.C. now have a low- cost, 192K memory upgrade (total), for the Atari 130XE. Best of all, unlike other memory upgrades, you do NOT loose the 130XE's Extended Antic modes! ALL 130XE type software (like Typesetter and Planetarium) run as normal! With the extra 64K of RAM, you can: Use Basic XE, and still have an additional 64K ramdisk! With the included instructions, you can set-up Atariwriter + (under SpartaDOS 2.3x/3.2x), for it's 3 main programs (AtariWriter+, Proof Reader, and Mail merge) to run from a ramdisk! Includes ramdisk handlers, to set-up a 707 sector (single density) ramdisk for Atari DOS 2.0S/2.5, source code, and other utilities. Also includes instructions for setting up ramdisk(s) with: MyDOS, TopDOS, SpartaDOS 2.3x /3.2x, and the new SpartaDOS X Cartridge. Price: $34.95 (+ $3.00 S&H) Note: Installation is required, by a person experienced in soldering and desoldering. NO trace cutting required! ST Section ----------------------------------------------------------------------- ST Filename Extender definitions Executable programs .PRG (GEM program) .TOS (TOS program) .TTP (Program which requires input) .RSC (Resource file) .DAT (Data file) .PIC (Picture file) .TXT (Text file) .DOC (Documentation file} .C ----- .MOD | .SRC | .PAS ^ .ASM (Source Code files) .BAS (BASIC program) .LOG (LOGO program) .SNG (Music Studio file) .NEO (NEOchrome drawing) .PI1 -------- .PI2 | .PI3 (Degas drawings) .PC1 -------- .PC2 | .PC3 (Compressed DEGAS Elite drawing) .TNY (Compressed TINY format picture) .TN1 -------- .TN2 | .TN3 (Compressed TINY2 format picture) .ARC (ARChived file) .PQ1 -------- .TQT | .PQG (SQUeezed files) .LBR (LIBraried files) .LQR (SQUeezed LIBrary files) .MSA (Magic Shadow Archived) PC Pursuit Recommendations Report ----------------------------------------------------------------------- Telenet Communication Corporation Field Operations HQ Tech Support Reston, Virginia Introduction Because of many customer complaints concerning PC Pursuit's inability to allow file transfers, Field Operations was requested to provide recommendations for file transfer via PC Pursuit. In compliance with this request, this document provides the following: * Recommendation on the best file transfer protocols to be used with PC Pursuit. * Recommendation on the hunt-confirm sequence and line parameters which provide optimum performance of various protocols. * The average transfer rates which can be expected using the correct hunt -confirm sequence and optional parameter settings. Recommendations This recommendation outlines the most common file transfer protocols used with PC Pursuit. The performance of the protocols in the direct connect and PC Pursuit environments are also indicated. The following protocols were tested via the Chicago in-dial to the Washington DC out-dial; the observations are summarized below. PC Pursuit XMODEM file transfers performed at an average throughput of 30 when the correct hunt-confirm and terminal type was utilized. XMODEM does not support flow control, therefore it is suggested that the "relaxed" mode be invoked if the user's communications software permits this feature. The performance of YMODEM file transfers VIA PC Pursuit was found to have an average throughput of 56 when the correct hunt confirm and terminal type is employed. Although YMODEM does not support flow control, it uses large 1024 byte packets which the network PAD handles quite readily under normal conditions. As a result, YMODEM is rated one of the faster protocols for file transfer via PC Pursuit. WXMODEM file transfers utilizing the correct hunt-confirm and terminal type performed well with an average transfer rate of 52. This protocol is capable of handling flow control which enables it to perform with better reliability in the PC Pursuit environment. Users should be aware that an early version of PROCOMM is known to have a software problem which can affect the performance of WXMODEM file transfers. An optimum average throughput of 47 was obtained by KERMIT file transfers via PC Pursuit. The throughput was optimized by modifying the packet size to 90 and adjusting the (host) window size to 16 (for uploads). KERMIT software which supports the sliding window feature performs with optimum efficiency in the PC Pursuit environment. SEALINK file transfers via PC Pursuit performed exceptionally well with an average throughput of 74 with the correct hunt-confirm and terminal type. SEALINK supports flow control and was specifically designed to operate in the networking environment. File transfers utilizing ZMODEM protocol via PC Pursuit yielded an average transfer rate of 61. ZMODEM performs well in the PC Pursuit environment, however; the local configuration for ZMODEM file transfers proved to be cumbersome and difficult for the user. ZMODEM requires several parameters to be set locally and on the local pad. These parameter settings can vary depending on the type of machine and the type of communications software. The X.3 PAD parameters which should be employed are 1:0,4:10,5:1,7:8,12:1. In addition, flow control (XON/XOFF) should be enabled at the user PC. Because of the difficulty in configuring ZMODEM for file transfer, it is recommended that only seasoned computer users attempt ZMODEM file transfers via PC Pursuit. The following text summarizes file transfer performance of the protocols tested. The protocols are listed in order (PCP best to worst) in two categories: 1) performance via direct connect, 2) performance via PC Pursuit utilizing the recommended hunt confirm and parameter settings shown. It should be noted that the optional parameters need only be employed if a user experiences problems with transferring a particular file. File Transfer Procedures This section outlines the step by step procedure for executing file transfers via PC Pursuit. These procedures must be followed exactly to achieve optimum transfer rates. The optional X.3 parameters shown above indicates the parameters which provide the best transfer rate. STEP 1 Set PC communications software to 8 bits, no parity, 1 stop bit, full duplex. Depending on the type of protocol to be used, disable or enable local (XON/XOFF) flow control. STEP 2 Dial local rotary with the communications software set at the desired speed. STEP 3 Upon answer use the correct hunt confirm sequence: At 300/1200bps use - <CR D CR> At 2400bps - <@ D CR> NOTE: "D" MUST BE UPPER CASE. STEP 4 At prompt "TERMINAL = " enter <D1> and return. STEP 5 At the "@" prompt enter the destination mnemonic, out-dial speed, ID and password. It is important that out-dial speed matches in-dial speed. DO NOT MIX IN-DIAL AND OUT-DIAL SPEEDS. STEP 6 If pad X.3 parameters are to be changed, do so at this point by entering <@ CR>. Set parameters as prescribed. Return to out-dial port by entering <CONT>. An example of the proper syntax for modifying X.3 PAD parameters would be "SET 7:8,1:0." To display the current PAD parameter settings, the user should enter "PAR?." These are only two of many user commands available. Many of the user commands are clearly defined in the Telenet document "How to Use Telenet's Asynchronous Dial Service." STEP 7 Upon connecting to the destination pad, insure communication with the out-dial modem by entering <ATZ>. The destination modem will respond with "OK". STEP 8 Enter <ATD> and the local number you wish to dial. STEP 9 Queue host file transfer and start file transfer. Please note that these are the basic steps needed to achieve successful file transfers. Since communications software may vary from package to package, additional steps may be needed to initiate the start of the file transfer at the user software level. Summary Extensive testing has resulted in identifying the expected performance of six file transfer protocols when used with PC Pursuit. These protocols have been determined to perform satisfactorily with PC Pursuit when the correct hunt-confirm, terminal type and parameters are employed. It is the recommendation of Field Operations that customers be informed of the correct logon procedures and the protocols which provide the most reliable file transfers. Customers should also be reminded that PCP users can expect a small degree of network delay which is considered a common characteristic of packet switched networks. In addition, users should also be informed that poor quality voice grade telephone lines can adversely affect file transfer sessions. Field Operations is one of many Telenet groups dedicated to providing customers with complete support for PC Pursuit. Field Operations will offer assistance with file transfer problems providing the customer is willing to release a copy of the problem software as well as provide the pertinent information necessary to resolve the problem. Because problems can vary in nature, the information required to resolve problems can differ from one problem to the next. But at the very least the following information will be required: * Type of communication software * Type of PC, make, model * Type of modem * Call origin * Call destination * Speed in * Speed out * Type of session * Time of failure * Date of Failure * Point of failure in session * Out-dial number * Network Address (if possible) * Copy of PC Software Additional information may be required depending on the nature of the problem. FILE TRANSFER--PERFORMANCE STATISTICS PERFORMANCE STATISTICS DIRECT CONNECT General Communication Parameters = 8 bits 1 stop bit N no parity Terminal Type = D1 PERFORMANCE STATISTICS DIRECT CONNECT | XFR | | PROTOCOL SPEED SECONDS CPS BPS RATE | |======================================================| | | | SEALINK UP 1200 ***517 87.15 871.49 73| | SEALINK UP 2400 ***270 166.87 1668.74 70| | SEALINK DN 1200 ***428 105.27 1052.71 88| | SEALINK DN 2400 ***230 195.90 1958.96 82| | ZMODEM UP 1200 ***408 110.43 1104.31 92| | ZMODEM UP 2400 ***201 224.16 2241.59 93| | ZMODEM DN 1200 ***391 115.23 1152.33 96| | ZMODEM DN 2400 ***195 231.06 2310.56 96| | YMODEM UP 1200 **259 102.80 1027.95 86| | YMODEM UP 2400 **126 211.30 2113.02 88| | YMODEM DN 1200 **244 109.11 1091.15 91| | YMODEM DN 2400 **130 204.80 2048.00 85| | WXMODEM UP 1200 **277 96.12 961.16 80| | WXMODEM UP 2400 **159 167.45 1674.47 70| | WXMODEM DN 1200 **405 65.74 657.38 55| | WXMODEM DN 2400 **131 203.24 2032.37 85| | KERMIT UP 1200 **356 74.79 747.87 62| | KERMIT UP 2400 **211 126.18 1261.80 53| | KERMIT DN 1200 **322 82.68 826.83 69| | KERMIT DN 2400 **178 149.57 1495.73 62| | XMODEM UP 1200 **259 102.80 1027.95 86| | XMODEM UP 2400 **140 190.17 1901.71 79| | XMODEM DN 1200 **268 99.34 993.43 83| | XMODEM DN 2400 **146 182.36 1823.56 76| ====================================================== **File size = 26624 ***File size = 45056 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Syndicate ZMagazine is Copyright (C)1988 by APEinc, Syndicate Pubishing. All Rights Reserved. Reprint permission granted in User Group Newsletters providing Syndicate ZMagazine and Issue #130 are credited. *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*